Code monitoring and restricting of egress operations

ABSTRACT

One example method of operation may include identifying an attempted action taken to code, determining whether to block the attempted action based on one or more of user profile access rights assigned to a user profile and a code permission assigned to the code, and responsive to determining whether to block the attempted action, blocking one or more of access to the code, access to a file containing the code and a port used to connect to a server hosting the code.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. non-provisional applicationSer. No. 17/178,233, filed on Feb. 17, 2021, which claims priority toU.S. provisional application No. 62/978,238, filed on Feb. 18, 2020,U.S. provisional application No. 62/978,240, filed on Feb. 18, 2020,U.S. provisional application No. 62/978,242, filed on Feb. 18, 2020,U.S. provisional application No. 62/978,245, filed on Feb. 18, 2020,U.S. provisional application No. 62/978,248, filed on Feb. 18, 2020, andU.S. provisional application No. 62/978,250, filed on Feb. 18, 2020, theentire disclosures of which are incorporated by reference herein.

BACKGROUND

Conventionally, software development utilizes an access portal to reachthe code source whether it resides on an internal enterprise platform ina remote cloud location, such as ‘GITHUB’ or other third party clouddevelopment sources. A username and/or password is not a viable solutionto managing an entire team of developers and their respective accessrights. Developers know all the vulnerabilities and can equally be athreat as well as a valuable asset to the team of developers and thecode development project.

On the other hand, the strict restrictions which prevent access tovarious lower level employees or other contractors which are not part ofthe elite circle of senior developers, only limits the growth potentialof a development team since many developers may be performing both lessimportant and more important development tasks. In such circumstances,the developer may require access to the portions of code which aredeemed sensitive and which the developer may not currently have accessto at a particular time.

One common concern is how to provide a fundamental level of code accesswithout permitting any unnecessary rights or privileges to the codedevelopment personnel. For example, when a low-level developer needs toexecute code to perform fundamental functions, however, the additionalprivileges, such as viewing, copying, changing, saving, etc., are allnot necessary functions for that particular user profile, then the idealscenario would include access to perform tests and related operationswithout any additional privileges.

SUMMARY

Example embodiments of the present application provide at least a methodthat includes identifying a code access event associated with a codesegment, determining whether one or more portions of the code segmentrequire code access permissions, determining whether one or morecredentials of a profile associated with the code access event have arequired code access credential necessary to permit the code accessevent, and assigning limited access to the code segment and the profilebased on the one or more credentials associated with the code accessevent

Another example embodiment may include an apparatus that includes aprocessor configured to identify a code access event associated with acode segment, determine whether one or more portions of the code segmentrequire code access permissions, determine whether one or morecredentials of a profile associated with the code access event have arequired code access credential necessary to permit the code accessevent, and assign limited access to the code segment and the profilebased on the one or more credentials associated with the code accessevent.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform, identifying a code access eventassociated with a code segment, determining whether one or more portionsof the code segment require code access permissions, determining whetherone or more credentials of a profile associated with the code accessevent have a required code access credential necessary to permit thecode access event, and assigning limited access to the code segment andthe profile based on the one or more credentials associated with thecode access event.

Yet another example embodiment may include a method that includesidentifying a code segment accessed during a code access event, scanningcode of the code segment to identify a degree of sensitivity of thecode, appending a code access annotation to the code segment based ondetected actions performed to the code during the code access event, andupdating a code log to identify the code access annotation.

Still yet a further example embodiment may include an apparatus thatincludes a processor configured to identify a code segment accessedduring a code access event, scan code of the code segment to identify adegree of sensitivity of the code, append a code access annotation tothe code segment based on detected actions performed to the code duringthe code access event, and update a code log to identify the code accessannotation.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform identifying a code segmentaccessed during a code access event, scanning code of the code segmentto identify a degree of sensitivity of the code, appending a code accessannotation to the code segment based on detected actions performed tothe code during the code access event, and updating a code log toidentify the code access annotation.

Still another example embodiment may include a method that includesdetermining one or more of a file type and a code segment accessedduring a code access event, identifying code origin information appendedto the code segment during previous code access events, appending anupdated code access location to the code segment identifying the currentcode access event and a current code location, and applying one or morecode access restrictions to the code segment based on the current codelocation.

Still yet another example embodiment may include an apparatus thatincludes a processor configured to determine one or more of a file typeand a code segment accessed during a code access event, identify codeorigin information appended to the code segment during previous codeaccess events, append an updated code access location to the codesegment identifying the current code access event and a current codelocation, and apply one or more code access restrictions to the codesegment based on the current code location.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform determining one or more of a filetype and a code segment accessed during a code access event, identifyingcode origin information appended to the code segment during previouscode access events, appending an updated code access location to thecode segment identifying the current code access event and a currentcode location, and applying one or more code access restrictions to thecode segment based on the current code location.

Still another example embodiment may include a method that includesidentifying a plurality of code access events over a period of time,determining whether any of the code access events included any sensitivecode segments, determining whether any of the code access events whichincluded the sensitive code segments were unauthorized, and performingone or more automated actions to restrict code access permissions of oneor more user profiles.

Still yet another example embodiment may include an apparatus thatincludes a processor configured to identify a plurality of code accessevents over a period of time, determine whether any of the code accessevents included any sensitive code segments, determine whether any ofthe code access events which included the sensitive code segments wereunauthorized, and perform one or more automated actions to restrict codeaccess permissions of one or more user profiles.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform identifying a plurality of codeaccess events over a period of time, determining whether any of the codeaccess events included any sensitive code segments, determining whetherany of the code access events which included the sensitive code segmentswere unauthorized, and performing one or more automated actions torestrict code access permissions of one or more user profiles.

Still another example embodiment may include a method that includesidentifying an attempted action taken to code, determining whether toblock the attempted action based on one or more of user profile accessrights assigned to a user profile and a code permission assigned to thecode, and responsive to determining whether to block the attemptedaction, blocking one or more of access to the code, access to a filecontaining the code and a port used to connect to a server hosting thecode.

Still another example embodiment may include an apparatus that includesa processor configured to identify an attempted action taken to code,determine whether to block the attempted action based on one or more ofuser profile access rights assigned to a user profile and a codepermission assigned to the code, and responsive to determination as towhether to block the attempted action, block one or more of access tothe code, access to a file containing the code and a port used toconnect to a server hosting the code.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause a processor to perform identifying an attempted actiontaken to code, determining whether to block the attempted action basedon one or more of user profile access rights assigned to a user profileand a code permission assigned to the code, and responsive todetermining whether to block the attempted action, blocking one or moreof access to the code, access to a file containing the code and a portused to connect to a server hosting the code.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an example code limited access managementconfiguration according to example embodiments.

FIG. 1B illustrates an alternative example code limited accessconfiguration according to example embodiments.

FIG. 1C illustrates another alternative example code limited accessconfiguration according to example embodiments.

FIG. 1D illustrates an example limited access code access operationperformed by a user device according to example embodiments.

FIG. 1E illustrates an example limited access code access recording andmanagement operation according to example embodiments.

FIG. 1F illustrates an example flow diagram of an example process forproviding limited code access according to example embodiments.

FIG. 2A illustrates an example code annotation and documentationmanagement configuration according to example embodiments.

FIG. 2B illustrates another example code annotation and documentationmanagement configuration according to example embodiments.

FIG. 2C illustrates an example code annotation and documentationmanagement configuration for multiple code according to exampleembodiments.

FIG. 2D illustrates an example flow diagram of an example process fordocumenting code access events according to example embodiments.

FIG. 3A illustrates an example network diagram of multiple code accessinstances and established provenance of the code modification eventsaccording to example embodiments.

FIG. 3B illustrates an example network diagram of multiple code accessinstances and established provenance of the code modification eventswith code trace data according to example embodiments.

FIG. 3C illustrates an example flow diagram of a process forestablishing provenance of the code modification events according toexample embodiments.

FIG. 4A illustrates an example user interface of a code audit processfor detecting code instances on a network according to exampleembodiments.

FIG. 4B illustrates a network device which performs example codedetection for code use and related code events according to exampleembodiments.

FIG. 4C illustrates an example configuration for detecting codeinstances on a network according to example embodiments.

FIG. 4D illustrates an example flow diagram of a process for managingcode instances on a network according to example embodiments.

FIG. 5A illustrates an example network configuration for detecting codeegress according to example embodiments.

FIG. 5B illustrates an example network configuration for monitoring codeegress and according to example embodiments.

FIG. 5C illustrates an example flow diagram of a process for managingcode egress attempts according to example embodiments.

FIG. 6A illustrates an example network configuration for applying codesecurity via token access according to example embodiments.

FIG. 6B illustrates an example network configuration for enforcing codesecurity via token access according to example embodiments.

FIG. 6C illustrates an example network configuration for applyingdifferent tokens to different code segments according to exampleembodiments.

FIG. 6D illustrates an example flow diagram of a process for enforcingtoken access according to example embodiments.

FIG. 7 illustrates an example network entity device configured to storeinstructions, software, and corresponding hardware for executing thesame, according to example embodiments of the present application.

DETAILED DESCRIPTION

It will be readily understood that the components of the presentapplication, as generally described and illustrated in the figuresherein, may be arranged and designed in a wide variety of differentconfigurations. Thus, the following detailed description of theembodiments of a method, apparatus, and system, as represented in theattached figures, is not intended to limit the scope of the applicationas claimed, but is merely representative of selected embodiments of theapplication.

The features, structures, or characteristics of the applicationdescribed throughout this specification may be combined in any suitablemanner in one or more embodiments. For example, the usage of the phrases“example embodiments”, “some embodiments”, or other similar language,throughout this specification refers to the fact that a particularfeature, structure, or characteristic described in connection with theembodiment may be included in at least one embodiment of the presentapplication. Thus, appearances of the phrases “example embodiments”, “insome embodiments”, “in other embodiments”, or other similar language,throughout this specification do not necessarily all refer to the samegroup of embodiments, and the described features, structures, orcharacteristics may be combined in any suitable manner in one or moreembodiments.

In addition, while the term “message” has been used in the descriptionof embodiments of the present application, the application may beapplied to many types of network data, such as, packet, frame, datagram,etc. For purposes of this application, the term “message” also includespacket, frame, datagram, and any equivalents thereof. Furthermore, whilecertain types of messages and signaling are depicted in exemplaryembodiments of the application, the application is not limited to acertain type of message, and the application is not limited to a certaintype of signaling.

Example embodiments provide ways to enforce software code access andpermissions to protect code from unauthorized sources attempting to gainaccess to the code. Code access, in general, may invoke a managerialevent, such as an automated identification procedure to identify whetherthe code attempting to be accessed, or more specifically, the codesegment that was specifically accessed, is permitted to be accessed,altered, etc. Also, a determination may be made as to whether the codewas tampered, copied, etc., especially when the profile associated withthe access attempt during the code access event has limited rights toaccess and modify the code.

In one example, any action by a particular user device profile or userprofile, which identifies a particular individual and/or device, andwhich is currently logged into the code repository application, may bescreened, corroborated/intercepted by a managerial agent applicationfunction. Any known policies are applied on the fly during such eventsor periodically during audits of such events which may be performed atcertain intervals of time during an active code access session. Forexample, a policy may be applied at the initial access event, such aswhen credentials are received and access is granted. The policies may berecursively applied or checked by the managerial agent at the expirationof certain periods of time, such as every 10 minutes. The policies maybe applied by attempting to identify a device being used asrecognized/not recognized, an amount of code access attempts, such as anumber of code segments, a number of code files, a total amount of codeaccessed (e.g., measured in bytes). Other audited actions may be anumber of modifications made, measured in bytes or individual changessaved. The criteria for identifying the access compliance measuresapplied during the policy enforcement efforts may be based on numericalthresholds of bytes, numbers of changes, lines of code, numbers offiles, etc.

According to one example, one specific function may be to select alimited portion of the total available code which is identified asauthorized based on a user profile permission or other monitoring andmanagement criteria. Further to the code access operation andapplication of permissions/restrictions, the code may have selectiveaccess applied to certain code blocks/segments based on the rights,statuses, and/or other credentials associated with the user profiles oruser devices accessing the code. For example, within a certain definedcode access may include the ‘code’ 122 which defines all the coderelated to the recent access operation. The code may be partitioned intosegments 124, which are sub-portions of the code. Within a code segment124 may be a code block 126, which is identified as the most fundamentalamount of code described with reference to the examples described in theexample embodiments.

FIG. 1A illustrates an example code access network configurationaccording to example embodiments. Referring to FIG. 1A, the network 100includes an enterprise network 110 which represents a location where oneor more user managed devices 102 may attempt to access 112 a coderepository on a local enterprise server 104 and/or a remote coderepository server 120 to access stored code. The credentials 106 may bebased on a user profile or other credential management procedure, andmay be stored in a database where the access permissions are identifiedand granted/denied. The code access attempts 112 may also be forwardedto a code repository server 120 in the cloud and permissions may beapplied based on the stored credentials 106. Once access is granted thecode 122 may be accessed, or a code segment 124 or even a code block126, which is a sub-set of a segment 124 depending on how thepermissions 114 are enabled.

FIG. 1B illustrates another example of a code access networkconfiguration according to example embodiments. Referring to FIG. 1B,the example 150 provides accessing code in a code repository which isstored and managed by the enterprise network 110. In this example, thecode is not stored in the cloud or a remote network and is insteadstored locally and managed internally.

FIG. 1C illustrates yet another example code access networkconfiguration according to example embodiments. Referring to FIG. 1C,the configuration 160 includes a code repository 120 in the cloud andnot in the enterprise network 110. The code access attempts 112 areforwarded to the remote site 120 and the permissions 106 are applied 114in the cloud network, which maintains the registration information andthe access information necessary to obtain access to the code 122. Theservers which maintain the code or provide access to the code may be oneand the same and may be in the cloud, in a local network or both.

In one example, an agent may be installed on a user device 102 tomaintain constant communication with an agent application on theenterprise server 110. An identity of a user device may be confirmedfrom credentials which are stored on the device and forwarded during anaccess attempt. For example, a personal access token may be required toobtain access to the code repository. A software source code securityfunction may be stored in the third party cloud code source. The agentapplication may be periodically auditing the user device 102 to ensurethe permissions are active and the actions taken are consistent with thepermissions associated with that particular user device 102. In oneexample of tracking code and code events, a code copy may be known toexist in a code repository based on a data file directory and/or datafiles containing the code in a particular at a particular storagelocation. In one example of tracking code and code “copy” permissions, acode copy may be detected between an enterprise repository and a datafile directory and/or data files containing the code at a particularstorage location.

In another example, the access levels may include full access withadministrative capabilities to modify code, source code, other types ofrelated code, access various libraries and sites including multiple testsites and/or backup sites. Another level of access may include theability to view and access all of the code but not make changes to thecode except for designated portions associated with a user profile ofthe access event. Another type of access may be a basic and mostfundamental access option which includes permitting access to the systemtest platform and not the main source code, however, the code may beblurred or invisible or not accessible and only certain testing platformfunctions may be accessible, such as testing procedures which are storedseparately from the source code, such as a testing module or“container”. Those testing procedures may be executed to test the code,compile the code and receive results, however, being able to change thecode, view the code and access certain code portions may be whollyinaccessible by such basic access level. Conventional approaches maymanually split the repositories into multiple repositories wheneverpossible. This approach can be cumbersome and difficult to manage andthus layering permissions on top of the existing repositories is morelogical for added security measures.

FIG. 1D illustrates an example limited access code access operationperformed by a user device according to example embodiments. Referringto FIG. 1D, the example configuration 170 illustrates how a user devicethat has received partial access to code may be subject to code accesscriteria 130 which is managed by a server managing the code access andmonitoring code access events. In this example, the user device 102 hasreceived limited access to the code 122, by having code segments ‘A’ 132and ‘C’ 136 accessible and not having access to the segment ‘B’ 134. Theaccess criteria is assigned to the device/user profile. The access islimited which indicates that not all types of actions can be taken, forexample, the device 102 may not be able to copy or delete code, however,the profile may be able to access, view, read, write and save changes,as identified from the criteria 130. The other portions of the code,such as segment ‘B’ may be accessible and visible, however without anytype of modification rights. Alternatively, the non-permitted code maybe invisible to the profile/device 102 as access may be denied entirely.

FIG. 1E illustrates an example limited access code access recording andmanagement operation according to example embodiments. Referring to FIG.1E, the example 180 includes applying the profile access rights(criteria) to the code access system. The access will remain limited,the segments of code are limited and the actions permitted are limited.The example includes accessing code segment ‘A’ 132 and performing aread, write, and save operation to both sub-portions including block ‘A’142 and block ‘B’ 144. The example also includes attempting a copyoperation to block ‘A’ 142, which is flagged by the code repositoryserver 120, which in this example is enforcing the limited accessrights, however, any device could enforce the rights including an agentoperating on the user device 102. The copy operation is not permitted inthis example. Once the permitted and non-permitted actions arecompleted, the datastore 140 may store the access time, date, userprofile, device profile, actions attempted, actions successful, actionsrejected, etc.

FIG. 1F illustrates an example flow diagram of an example process forproviding limited code access according to example embodiments.Referring to FIG. 1F, one example 190 may include identifying a codeaccess event associated with a code segment 192, and determining whetherone or more portions of the code segment require code access permissions194. The code may have separately stored portions or commonly storedportions separated by different files or access credential requirements.The portions of code may be referred to as code segments. The codesegments may have blocks which are accessed to work and modifyline-by-line code and in this example are the most fundamental portionof code, and which can be tracked, monitored, controlled and havelimited access applied. The process may also include determining whetherone or more credentials of a profile associated with the code accessevent have a required code access credential necessary to permit thecode access event 196. The credentials may be based on assigned rightsof the profile, a user device hardware profile, a network address,historical access information, etc. The process may also includeassigning limited access to the code segment and the profile based onthe one or more credentials associated with the code access event 198.The profile may be paired with the credentials during the login oraccess process. The credentials may be collected from various differentsources and used to comply with the access rights at any given time. Ifthe credential information cannot be collected or some of theinformation is not available during access times, the access rights canbe severely limited.

When one or more portions of the code segment require code accesspermissions, the process may include assigning one or more of a limitedview permission, a limited modification permission, and no accesspermission, to the one or more credentials and permitting the codeaccess event. Also, the limited access is assigned to one or more blocksof code of the code segment, and the limited access permits access tothe one or more blocks of code but not all blocks of code of the codesegment. Generally, most profiles will not receive access to allportions of the code. The process may also include assigning the limitedaccess to the code segment by permitting the code segment to be compiledand executed by a user device associated with the one or morecredentials and the profile while not providing access to the codesegment code. The one or more credentials include one or more of atoken, a password, a device hardware address, a network address, and aconfirmation of a previous access operation. The process may includedetermining whether to block or permit the code access event based onprofile access permissions associated with the profile, and permittingthe profile to access one or more code segments among a plurality ofadditional code segments. The process may also include creating a log ofactions performed to the one or more code segments, and applying the logas a new credential to the profile.

Example embodiments provide ways to enforce software code access andmodification to protect code from unauthorized sources and to track theuse of the code on developer devices ‘workstations’. Further to codeaccess operations and application of permissions/restrictions to thecode, the code may be accessed and then annotated, tracked, modified,etc. Also, the code's access and changes may be stored to create a codehistory throughout the access operations both in the enterprise and thecloud. This may include access and changes associated with devices anduser profiles/devices associated with accessing the code. One exampleincludes identifying which devices accessed the code, what portions ofthe code are permitted to be accessed, annotating the actions taken bycertain user profiles/devices. For example, user ‘A’, device ‘ABC’, at atime 10:01 AM, added certain attributes, copied, saved, updated, codesegments ‘A’ and ‘B’ and sub-blocks ‘DEF’ and ‘XYZ’, etc. Also,identifying other access efforts, such as user ‘profiles A’ and user ‘B’both accessed the code, two copies are circulating at a current time andare tied to the original code source, all such actions are identified,annotated and saved with the original code log or as metatags linked tothe code to document those instances with a timestamp and otherinformation necessary to recall such events during an audit operation.

According to one example, one specific function may be to select alimited portion of the code which is properly accessed and authorizedbased on a user profile permission or other governing criteria. Furtherto the code access and application of permissions/restrictionsassociated with the user profile/user device, the code may haveselective access applied to certain code blocks/segments based on therights, status, and/or other credentials associated with the userprofiles or user devices accessing the code. All subsequent code relatedactions are documented for later audit purposes.

FIG. 2A illustrates an example code annotation and documentationmanagement configuration according to example embodiments. Referring toFIG. 2A, the configuration 200 may include a code repository server 120which may be a local enterprise server or a server maintained at a thirdparty source, such as ‘GITHUB’ which can be used to access code andmanage code development efforts. When one or more user devices 102/103attempt to access the server 120 and retrieve, access and/or modifycode, the code may be organized as segments or blocks 226 which may beaccessed according to one or more code access permissions/restrictions206 associated with the user devices 102/103. Each device profile mayhave a unique copy of the code blocks/segments 225/227 depending on thepermissions and rights associated with the user devices 102/103. Anannotation(s) 232 may be appended to the main version or code repositoryversion to reflect which user device/profile accessed the code and madechanges to the code. In another example, the code segment may be copiedand supplied to the user devices as separate versions 225/227 of thesame code.

FIG. 2B illustrates another example code annotation and documentationmanagement configuration according to example embodiments. Referring toFIG. 2B, in an active code access scenario, the configuration 250 mayinclude each user device having one or more code segments accessible totheir respective devices 102/103. The code may be subject torestrictions 206 which are applied 252 actively during code access anddevelopment sessions via an agent application operating on the userdevices. Also, each copy of the code, code storage location, codemodification, blocked access attempt, etc., which is performed is loggedin code access log 240 as part of an active log or a periodic log auditfunction. In this example, the user devices 102/103 may be performingoperations, such as modifying code via a particular storage location‘ABC’ and via particular code blocks ‘XYZ’, user device 103 may performa separate copy of particular location ‘ACD’ to modify code blocks‘XYA’. The efforts are unique and based on a common code. However, thecopies of the code 225/227 are separate and unique but may be combinedlater into the main code source. The device operations 246/248 arelogged in the log 240 as part of an audit 254 or each time the eventsoccur.

In one example, an agent may be installed on a user device 102 tomaintain constant communication with an agent application on the server.An identity of a user device may be confirmed from credentials, such asmulti-factor authentication (MFA) which are stored on the device andforwarded during an access attempt. For example, a personal access tokenmay be required to obtain access to the code repository. A softwaresource code security function may be stored in the third party cloudcode source. The agent application may be periodically auditing the userdevice 102 to ensure the permissions are active and the actions takenare consistent with the permissions associated with that particular userdevice 102. In another example, the user device access operation mayinvoke a library of software application versions be loaded onto theenterprise server to support the code management operations. Forexample, a code compiler may be loaded to support the user devicetesting and modifying the code so the code can be executed. One approachis to not permit changes to the developer code and test workflows bypermitting user profiles for testing only such as ‘compilers’ for mostcommon languages to selectively access code files.

FIG. 2C illustrates an example code annotation and documentationmanagement configuration for multiple code according to exampleembodiments. Referring to FIG. 2C, in this configuration 270, twoseparate workstations or user devices 102/103 are both accessing code atthe same time or in a manner overlapping one another. The code segmentaccessed may be the same code segment ‘B’, however, in this example, theseparate copies 225 and 227 may include customized changes to the codeidentified from the copies 134 and 136 stored on the devices 102/103. Inthis example, the user device 102 is accessing block data, such asblocks ‘A’ 142 and ‘B’ 144 from its own copied code of segment ‘B’ butnot ‘C’ 144. User device 103 is accessing blocks ‘B’ 144 and ‘C’ 146.Any modifications made may be combined into one version which is savedwith the original source code. The changes to block ‘B’ which may differfrom each device 102/103 may cause the changes/modifications to the codeto be merged into a single copy which is stored in the code repositoryserver 120. The changes may instead cause two versions to be storeduntil a final version can be authorized. The other approach may includeauthorizing changes for one block and only suspending changes to theblock being modified by both devices. So in that case, the changes to‘A’ 142 and ‘C’ 146 may be incorporated into the final code copy sincethere is not potential conflict between the two device versions sinceone device worked on one block and the other device worked on anotherblock, while the changes to ‘B’ 144 are maintained in two separatecopies until the changes can be authorized.

FIG. 2D illustrates an example flow diagram of an example process fordocumenting code access events according to example embodiments.Referring to FIG. 2D, the example process 290 may include identifying acode segment accessed during a code access event 292 by one or more userdevices authorized to access the code. The process also includesscanning code of the code segment to identify a degree of sensitivity ofthe code 294, this may include determining whether the code includescertain variables, global parameters, etc., which are deemed sensitive.Another criteria may include identifying whether the file associatedwith the code is marked sensitive by referencing a list of sensitivefiles. The process may also include appending a code access annotationto the code segment based on detected actions performed to the codeduring the code access event. This may include a timestamp, user profilename, user device identifier, etc. The information may be appended tothe code responsive to the access operation and/or added to a master log240 of access operations detected. The process may also include updatingthe code log to identify the code access annotation 298.

The process may also include identifying a file type associated with thecode segment, and applying selective access to the code segment based onthe identified file type. The applying of the selective access may beperformed to the code segment based on the identified degree ofsensitivity of the code. If the code is sensitive then the selectiveaccess may be invoked to limit portions of the code which include thesensitive criteria. When the code is determined to be sensitive then thecode access events may be required to be monitored and stored in theevent log. The process may also include periodically monitoring the codeaccess event to identify actions performed to the code segment duringthe code access event, and storing a record of each of the actionsperformed to the code segment in the event log. During code access, oneor more code access restrictions may be applied to the code segment, andthe one or more code access restrictions can include one or more of acode modification restriction, a code read restriction, and a code copyrestriction. The code access event may include one or more of a codedisplaying event, a code copy event and a code modification event.

Example embodiments provide ways to enforce software code protectionsand modifications to protect code from unauthorized sources and to trackthe use of the code on developer workstations. Code ‘provenance’ andapplication of permissions/restrictions to the code may include the codebeing accessed, annotated, tracked, modified, etc., according to thecode's history throughout the cloud and/or the enterprise computingenvironments and the user profiles/devices associated with the codeevents.

In general, identifying code access events may be performed by trackingaccess event data stored in a log or metadata of a file during aprovenance audit effort. This audit information can be retrieved andused to confirm code changes, locations, user profiles, and may alsoinclude details about the origin and current status of the code. Whenthe code is accessed, saved, audited, etc., the ‘provenance’ of the codemust be identified and confirmed to ensure the origin and last knownlocation are accurate prior to authorizing any further code accessevents and during a full code scan and deep inspection, such as a‘blueprint’ (all identified changes) analysis of all known code eventsand whether such events are authorized or outside the scope of themanagement criteria.

FIG. 3A illustrates an example network diagram of multiple code accessinstances and established provenance of the code modification eventsaccording to example embodiments. Referring to FIG. 3A, theconfiguration 300 illustrates a code server source, such as a coderepository 120 that provides access to developer workstations 302-306,which may be operating within an enterprise environment and which mayseek access to code for development purposes. When a code access eventis performed, the event is logged and identified in a master log storedand maintained in the server. Also, the code itself may be annotatedwith appended information, such as metadata, tags and/or labels whichproperly identify the code access event(s) times, locations and types ofmodifications.

During the access events, copies 322, 324 and 326 of the code 302, suchas portions of the code (code segments), which are authorized for codemodification purposes, may be retrieved and stored on the user devices302-306. Those copied and/or accessed versions of the code 322-326,which are utilized by the respective user devices 302-306 may beidentifiable via an audit tracing procedure that tracks all user devicesmanaged by a central server 120. In one example, certain lines of codemay be copied and used as the basis when scanning the user devicesduring an audit so the code audit application operating on the server120 can determine whether certain strings of code are included on thosedevices and whether the code that was copied is permitted to be used bythose devices. The scanning audit procedures may occur periodically(e.g., after a period of time) or in response to a trigger operation,such as when a device accesses the code or an authorization of access isperformed.

FIG. 3B illustrates an example network diagram of multiple code accessinstances and established provenance of the code modification eventswith code trace data according to example embodiments. Referring to FIG.3B, the example configuration 350 illustrates an example where thecopied code segments 332-336 may be portions of the master code 302,which were accessed and/or copied to the user devices. The resultingtrace data 340 may be a log of code data access and modification eventswhich are collected periodically to create a record of those eventsbased on trace records from audits over time. The auditing may be aperiodic event that occurs to identify whether code access andmodification events are taking place by any device that can be trackedand monitored. Information retrieved during a trace event may include,date, time, device storage location, device profile, user profile,network address, portions of the code which are copied/accessed.

According to one example, a first device 302 may access and copy codesegment 322 and a corresponding version of the code 332 will be createdand stored in the code repository for a temporary period of time and/oron the device 302. The code will be accessible and modifiable during thedefined period of time and as long as the access is active by the device302. When the inactivity is detected for a certain period of time, thecode will be saved and stored and access will be removed and willrequire additional authorization. Any changes, such as copying, new dataadded, new data removed, etc., will be logged in the trace data log 340along with the time, date, the user profile, the user deviceinformation, network information etc., Either concurrently orsubsequently, additional code access operations will be implemented bymore devices 304/306 and the process repeats by copying the code334/336, creating another code access and development session and whencompleted the trace data log 340 is updated to reflect an additionalaccess and code development process.

One example includes identifying code access events which are performedby tracking access event data stored in a log or metadata of a fileduring a provenance audit effort. This audit information can beretrieved and used to confirm code changes, code access and/or storagedevice locations, user profiles, and may also include details about theorigin and current status of the code. When the code is accessed, saved,audited, etc., the provenance record must be identified and confirmed toensure the origin and last known location are accurate prior toauthorizing any further code access events and during a brute forceinspection, such as a periodic trace analysis of all registered devices.

Another example embodiment may include tracking code by a chain ofcustody, such as by logging access events, such as the profiles whichaccessed, copied, changed, moved, and/or canceled code. Once code iscreated, certain ‘fingerprint’ characteristics may be created tocoincide with the code, such as metadata associated with the codeattributes, such as date of creation, certain variables, code length,dates of changes, user profiles accessed code, storage locations ofcode, size of data, etc. Other attributes include file names andportions of code, such as strings which are known to be proprietary tothe code development.

In one example of tracking code and code events, a code copy may beknown to exist in a code repository based on a data file directory andor data files containing the code at a particular storage location. Thecode attributes which define the code's presence, contents and/orstorage location may be identified and used as the basis for a bruteforce code tracking session, which may search known code repositories,such as online sites/links which are known for sharing code and othersoftware development tools. Other locations may include queries be sentto search engines to obtain results based on the code attributes. Filenames are one attribute, strings of code language are another attribute,each of which may be used to search for the code in unauthorizedlocations. Scanning code in public repositories may yield positive ornegative results as it pertains to the code being examined forduplicates and unauthorized copies.

In one example, if a file name or other code attribute is identified ina public repository, the code may be deemed stolen or breached. If thecode is discovered by a file name or other attribute, the code can thenbe copied and compared to the known versions of the code to ensure thereare enough matching attributes to yield an unauthorized copy. If so, theuser profiles linked to the code access operations in the enterpriselocation may be identified to identify the profiles associated withaccessing that code prior to the unauthorized code discovery event. Insuch an event, a token block may be requested to deny tokens which mayhave been previously available to user profiles to access the code. Atoken rotation may be initiated automatically responsive to the codebreach identification. This prevents previously authorized parties withtoken access from further access when the token is revoked or rotated.

FIG. 3C illustrates an example flow diagram of a process forestablishing provenance of the code modification events according toexample embodiments. Referring to FIG. 3C, the process 290 may includedetermining one or more of a file type and a code segment accessedduring a code access event 292, which may include identifying a label oridentifier that identifies the code that was accessed. The process alsoincludes identifying code origin information appended to the codesegment during previous code access events 294. For example, the codemay have a trace log with various instances of access and locationinformation stored in memory based on previous user device access andcode development instances. The process also includes appending anupdated code access location to the code segment identifying the currentcode access event and a current code location 296 to identify thecurrent access attempt and code development status. The process alsoincludes applying one or more code access restrictions to the codesegment based on the current code location 298. The criteria to allow,disallow, limit the amount of access time, permit/not permit codemodifications and copying may be based on access location, user profilesand other criteria.

The current code location may be based on one or more of a user profile,a corresponding device profile, and a network address. The informationis used to identify a location as acceptable or unacceptable in whichcase the code will be locked and unobtainable. The process also includesidentifying a previous code location from the metadata associated withthe code and updating code storage repository information based on thecurrent code location, and determining whether the current code locationis associated with code access privileges which match the previous codelocation. The code access and development privileges may vary dependingon the current location data stored in the code log metadata. When aknown location is identified, the privileges may include more optionsthan when the code is in a new location or an unknown location. In thisexample, the process may include applying one or more rules to thecurrent code location based on rules associated with the previous codelocation assuming that the new location is identified as an acceptablelocation. The process also includes performing a string comparison ofthe code segment to one or more other code segments, and the one or moreother code segments are additional copies of the code segment. In thisexample, portions of the code are taken as a match criteria and used toscan various machines across the Internet, at known development sitesand on known enterprise user devices to identify whether the code isavailable outside the code repository. This auditing process may be atest to identify if versions of the code are available in unauthorizedlocations. The process also includes detecting a plurality of codesegment copies which correspond to a plurality of code segment accessevents associated with the code segment, hashing the code segments, andstoring the hash key in a file associated with the code segment. Thisprovides a way to prevent unauthorized parties from accessing the code.The hashing of the code segment may provide storing the hash in a localdatabase and creating an index for efficient search efforts andreference purposes.

According to one example, one specific function may be to select alimited portion of the code which ‘checks-out’ ok based on a userprofile permission or other governing criteria. Further to the codeaccess and application of permissions/restrictions, the code may haveselective access applied to certain code blocks/segments based on therights, status, and/or other credentials associated with the userprofiles or user devices accessing the code.

In one example, an agent may be installed on a user device 102 tomaintain constant communication with an agent application on the server.An identity of a user device may be confirmed from credentials which arestored on the device and forwarded during an access attempt. Forexample, a personal access token may be required to obtain access to thecode repository. A software source code security function may be storedin the third party cloud code source. The agent application may beperiodically auditing the user device 102 to ensure the permissions areactive and the actions taken are consistent with the permissionsassociated with that particular user device 102.

Example embodiments provide ways to enforce software code protectionsfrom use and modification to the code from unauthorized sources, and totrack the use of the code on developer workstations. Further to codeprovenance and application of permissions/restrictions to the code, thecode may be accessed and then annotated, tracked, modified, according tothe code's history of use throughout the cloud and/or the enterpriseenvironment and the user profiles/devices associated with the codeevents. Also, the code may be periodically traced/audited to identifyall such events which have occurred over a period of time which includeaccessing, modifying, egress code operations (e.g., moving code, copyingcode, etc.), testing, authorization to access the code, etc. The codemay be stored in one known location, such as a master server 120,however, portions of the code may be used as the basis for determiningwhether other versions/copies of the code are available and whether theuse was authorized or unauthorized.

FIG. 4A illustrates an example user interface of a code audit processfor detecting code instances on a network according to exampleembodiments. Referring to FIG. 4A, the example 400 illustrates a userinterface with a summary of reporting operations, which demonstrates theresults of a scan/search/audit operation(s) that attempted to identifyall instances and related information of use, modification and storageof the code.

The code auditing/reporting results 400 may be realized by a server ordevices which are configured to track instances of metadata or controldata, such as: times, dates, locations, user profiles, egressoperations, copying operations, modifying operations, deletingoperations, etc., associated with the code. For example, generatedalerts 402 may include secrets identified 404, such as tokens used,private data, egress actions 406, such as policy violations,unauthorized actions, new public and private repositories 408 identifiedas storing the code, etc. The number of occurrences 410 may be used toestablish an acceptability/unacceptability threshold for action. Forexample, if the number of egress events for a period of time exceeds athreshold (T), such as five instances, then the code may be locked fromfurther access to all parties except for certain high leveladministrators. For example, if a copy of sensitive code is identifiedin five or more new locations within a defined period of time (Tt) thenan automated action may occur which prevents certain access and otherfunctions until the matter is resolved by reducing the number oflocations storing the code identified during a next audit process.Another operation may be a repository identification process where therepositories storing the code are identified and are required to beapproved to alleviate or remove an unauthorized action. The insightsidentified may include a summary of repositories identified 412, clonesof the code 414 and users, such as user profiles linked to the codeinstances 416.

One example of a period of time (Tt) may include 48 hours, one week,etc., that the code is tracked and the results are compiled and comparedto acceptability thresholds to determine if certain users are requiredto have their access privileges revoked. If a code use violation isidentified based on unacceptable storage locations or other criteria(e.g., time thresholds instances), then user rights of those withlow-level rights or those who accessed the code in those instances maylose their access privileges. Another criteria may be counting thenumber of duplications, such as clones created and where the clones arestored. A certain number of clones may be considered acceptable whileany number over that amount may be deemed unacceptable.

The various versions of the code may be identifiable via an audittracing procedure that tracks all user devices, repositories, etc.,identified by a central server application over a defined period oftime. For example, lines of code may be copied and used as the basis toscan various user devices during an audit so the code trackingapplication can determine whether certain strings of code are includedon those devices and whether the code that was copied is permitted to beused by those devices. Other criteria for code tracing includes filenames and execution paths of the code, which are traced for existencewithin the network being monitored.

FIG. 4B illustrates a network device which performs example codedetection for code use and related code events according to exampleembodiments. Referring to FIG. 4B, the configuration 450 includes theserver 120 responsible for storing and managing a master code copy 452.Each instance of the code being accessed, copied, modified, executed,etc., is tracked and stored in the log of trace data 458. For example,the code location, date, time, device information, code type, tokendata, egress actions, and/or score summary, etc., may all be part of theinformation stored with reference to a code event 454/456.

FIG. 4C illustrates an example configuration for detecting codeinstances on a network according to example embodiments. Referring toFIG. 4C, the code repository server 120 may attempt to perform a traceaudit that is based on a core code 462, which represents one or morecode builds which are maintained as master copies. The master copies 462are used as the basis for software code audits performed on a network464, such as the Internet, a private Intranet, an enterprise entity,etc. In general, the code tracing audits should be performed on targetedlocations where the code is likely to be stored, for example, thesoftware development sites used by many are excellent sources toidentify code use and unauthorized code usage. When the code or copiesof the code are identified as being in one or more unauthorizedlocations, then the code may be locked from access at the coderepository source 120 until the unauthorized locations have been securedor the code is removed. Any of the devices in the network 464 which areauthorized to access the code may be omitted from the unauthorized codeuse list data. A total number of code existence, use, etc., violationsmay be applied to a weighted function which weights each unauthorizedcode instance (location, execution, modification, etc.) to create a sumfor a total amount of unauthorized instances. The score may be a basisfor temporarily preventing code access and other code restrictions(e.g., execution, storage, etc.).

The trace data 458 may be a tally report of data for all instances ofthe code identified over a period of time. For example, code records454/456 may include a location, date, time, device profile, code type,token data, egress actions, etc., and scores which are summarized basedon the results of code monitoring operations. Each violation orunexpected occurrence may cause the score to increase causing anautomated action to occur. The trace/monitor data 458 may be a log ofcode data access events which are collected periodically to create arecord of those events based on trace records from audit operations. Theauditing may be a periodic event that occurs to identify whether codeaccess events are taking place by any device that can be tracked andmonitored. Information retrieved during a trace event may include, date,time, device storage location, device profile, user profile, portions ofthe code which are copied/accessed.

One example includes identifying code access events which are performedby tracking access event data stored in a log or metadata of a fileduring a provenance audit effort. This audit information can beretrieved and used to confirm code changes, locations, user profiles,and may also include details about the origin and current status of thecode. When the code is accessed, saved, audited, etc., the ‘provenance’or record must be identified and confirmed to ensure the origin and lastknown location are accurate prior to authorizing any further code accessevents and during a brute force inspection, such as a periodic traceanalysis of all registered devices. All such data is stored in the audittrace list 458.

Another example embodiment may include tracking code by a chain ofcustody, such as by logging access events, such as the profiles whichaccessed, copied, changed, moved, and/or canceled code. Once code iscreated, certain ‘fingerprint’ characteristics may be created tocoincide with the code, such as metadata associated with the codeattributes, such as date of creation, certain variables, code length,dates of changes, user profiles accessed code, storage locations ofcode, size of data, etc. Other attributes include file names andportions of code, such as strings of code which are known to beproprietary to the code development.

In one example of tracking code and code events, the code copy may beknown to exist in a code repository based on a data file directory andor data files containing the code in a particular storage location. Thecode attributes which define the code's presence, contents and/orstorage location may be identified and used as the basis for a bruteforce code tracking session, which may search known code repositories,such as online sites/links which are known for sharing code and othersoftware development tools. Other locations may be identified by queriesbeing sent to search engines to obtain results based on the codeattributes and network entities associated with the queries. File namesare one attribute, strings of code language are another attribute, eachof which may be used to search for the code in unauthorized locations.Scanning code in public repositories may yield positive or negativeresults as it pertains to the code being examined for duplicates andunauthorized copies.

In one example, if a file name or other code attribute is identified ina public repository, the code may be deemed stolen or breached. If thecode is discovered by a file name or other attribute, the code can thenbe copied and compared to the known versions of the code to ensure thereare enough matching attributes to yield an unauthorized copy. If so, theuser profiles linked to the code access operations in the enterpriselocation may be identified to identify the profiles associated withaccessing that code prior to the unauthorized code discovery event. Insuch an event, a token block may be requested to deny tokens which mayhave been previously available to user profiles to access the code. Atoken rotation may be initiated automatically responsive to the codebreach identification. This prevents previously authorized parties withtoken access from further access when the token is revoked or rotated.

FIG. 4D illustrates an example flow diagram of a process for managingcode instances on a network according to example embodiments. Referringto FIG. 4D, the example process 490 includes identifying a plurality ofcode access events over a period of time 492, and determining whetherany of the code access events included any sensitive code segments 494,and this may include any screened portions of the code which are tracedto identify access, execution, modification and/or egress of the codefor any reason. The actions taken will cause the code to be identified.The process may also include determining whether any of the code accessevents which included the sensitive code segments were unauthorized 496,and performing one or more automated actions to restrict code accesspermissions of one or more user profiles.

The one or more automated actions may include one or more of revokinguser profile code access permissions, locking access to the sensitivecode segments, and preventing code egress operations, and the codeegress operations may include one or more of moving the code, copyingthe code and storing the code in a new data storage location. Whencalculating the risk or relative amount of code instances, summing theweights assigned to the unauthorized code access events will provide abenchmark that can be used to compare to a threshold. By creating ascore based on the summed weights and determining whether the scoreexceeds a threshold a decision can be made to increase or decrease orleave alone the restrictions on the code. When the score exceeds thethreshold, a code access violation notification may be created andlogged or used to notify the interested parties.

The process may also include initiating a code audit operation whichidentifies the code access events over a period of time based on codeevents stored in a code log, determining whether a number of code cloneevents exceeded a clone event threshold, and creating an alert when theclone event threshold is exceeded and locking access to the sensitivecode segments. A code clone may be an exact copy of a code, or a copythat is substantially similar enough to be considered a clone whenidentifying additional copies of code. Also, determining whether the oneor more unauthorized code access events were based on unauthorized codestorage locations, unauthorized user profiles, and access attempts whichdid not use authorized tokens may provide a basis for code enforcementof unauthorized actions. Also, a machine learning procedure may beapplied to track a chain of custody of the code.

The one or more automated actions may include one or more of revokinguser profile code access permissions, locking access to the sensitivecode segments, and preventing code egress operations, and the codeegress operations include one or more of moving the code, copying thecode and storing the code in a new data storage location. The method mayinclude summing weights associated with the unauthorized code accessevents, creating a score based on the summed weights, determiningwhether the score exceeds a score threshold. When the score exceeds thescore threshold, a code access violation notification may be created.The method may also include initiating a code audit operation whichidentifies the code access events over the period of time based on codeevents stored in a code log, determining whether a number of code cloneevents exceeded a clone event threshold, and creating an alert when thethreshold is exceeded and locking access to the sensitive code segments.The method may also include determining whether the one or moreunauthorized code access events were based on unauthorized code storagelocations, unauthorized user profiles, and access attempts which did notuse authorized tokens. The method may further include applying a machinelearning procedure to track a chain of custody of the code.

In one example, an agent may be installed on a user device to maintainconstant communication with an agent application on the server. Anidentity of a user device may be confirmed from credentials which arestored on the device and forwarded during an access attempt. Forexample, a personal access token may be required to obtain access to thecode repository. A software source code security function may be storedin the third-party cloud code source. The agent application may beperiodically auditing the user device to ensure the permissions areactive and the actions taken are consistent with the permissionsassociated with that particular user device. In another example, theuser device access operation may invoke a library of softwareapplication versions be loaded onto the enterprise server to support thecode management operations. For example, a code compiler may be loadedto support the user device testing and modifying the code so the codecan be executed.

Example embodiments provide ways to enforce software code protectionsand modifications to protect code from unauthorized sources and to trackthe use of the code on developer workstations. Further to codeprovenance efforts and the application of permissions/restrictions tothe code, developers may access the code and annotate, track, modify,the code. The code events applied to the code may create history datathat is identified as the code is referenced throughout the cloud and/orthe enterprise environment, and based on the user profiles/devicesassociated with the code events. Also, the code may be periodicallytraced to identify all such events which have occurred over a period oftime which include accessing, modifying, egress code operations (e.g.,moving code, copying code, etc.), testing, authorization granted toaccess the code, etc.

FIG. 5A illustrates an example egress code monitoring and reportingconfiguration according to example embodiments. Referring to FIG. 5A,the configuration 500 includes an enterprise server 104 as an entityused to manage the access and/or storage of the code. When a use profileattempts to access code, the user profile of the client device may beretrieved from the data storage 106. The agent application 514 maycommunicate to a server agent application 512, which monitors the clientactions and reports the actions to an authority. Also, any violations tothe rights of the client device may cause the privileges to beautomatically revoked.

The enterprise server 104 may store the code in a code repository server120. When a code retrieval action 524 is received, the code 522 may beidentified as a particular segment, group, file or set of files whichare identified as having a particular designation, such as a restrictionor open access policy. Once the client profile is identified as havingaccess to the code, the code action (copy, modify, delete, execute,etc.) attempt 532 may be identified and the corresponding portions ofcode may be selected (code segment/block) and the entire procedure maybe logged to capture the code event history. In the event that theclient device is attempting any type of egress action, such as to move,copy or duplicate the code, the ‘egress’ attempt is identified 534 andthe action may be blocked 536. For example, when a client deviceattempts to copy the code from a server, such as by a client device andprofile that has write and edit permissions, but not necessarilypermission to remove the code, one approach is to detect, reference thepermissions of the user profile and then block the egress action.

Metadata can be monitored in association with the code and/or acorresponding data file, and an attempted copy action of a file may bedetected and blocked as a data loss prevention operation. Anotherapproach may be to block the port used by the server/client device tocommunicate and thus this will thwart an attempted code egress action.The port may be a client device port, a network device port, a serverport, etc. Also, the code does not have to be a file and instead couldbe a portion of code inside a file that includes various code portions.Also, a token may be used as an authentication factor, such as usernameand password, a device profile, etc.

FIG. 5B illustrates an example network configuration for monitoring codeegress and according to example embodiments. Referring to FIG. 5B, theexample 550 includes a scenario where the egress action is permitted552. In this case, the user profile/user device is managed via a clientagent application 514 which confirmed with the server agent application512 that the client permissions permitted the egress code action. As theaction is performed, via a code copy, code location modify operation, orsimilar egress operation, the client agent 514 flags the server agent512 by sending a request for confirmation of such egress privileges. Theconfirmation process may include examining the code segment, code block,etc., which is in question and comparing it to the user profile forconfirmation of the correction permissions/privileges. Once the egressaction is permitted, the server(s) may monitor the actions 554 of theclient device. The actions being monitored may be based on a time framepermitted for the egress of the code to the client device. For example,how long this data may be copied and stored temporarily on the clientdevice before the egress operation is deemed invalid or disallowed. Oncethe time frame has matured, the server may not provide additionalcommunication capabilities and the code can no longer be tied to anyother code executables which could limit other testing or simulationcode operations which require access to the core code or main executablefiles, and this would effectively revoke access.

FIG. 5C illustrates an example flow diagram of a process for managingcode egress attempts according to example embodiments. Referring to FIG.5C, the process 590 may include identifying an attempted action taken tocode, such as code being accessed by a client device during a codeaccess event 592, determining whether to block the attempted actionbased on one or more of user profile access rights assigned to a userprofile and a code permission assigned to the code 594, and responsiveto determining whether to block the attempted action, blocking one ormore of access to the code, access to a file containing the code and aport used to connect to a server hosting the code 596. The process mayalso include identifying the code being accessed and identifying thefile containing the code being accessed. The blocking of access to thefile may include identifying a metadata tag stored in the file andapplying a metadata tag rule to the file during the attempted action.The metadata tag may be a limiting rule that is enforced when the codeis accessed. The metatag may specify no egress type actions and thuswhen those are attempted on a code segment having the metadata tagswhich limit those actions, the egress operations may be blocked or atleast enforced to identify whether the user profile has the correctcredentials.

In general, code monitoring may include a server or devices which areconfigured to track instances of metadata or control data, such as:times, dates, location, user profiles, egress operations, copying,modifying, deleting, etc., associated with the code. For example, alertsmay include secrets identified, such as tokens used, private data,egress actions, policy violations, unauthorized actions, new public andprivate repositories, which are identified as storing the code. Thenumber of occurrences may be used to establish anacceptability/unacceptability threshold for action. For example, if thenumber of egress events for a period of time exceeds a threshold (T) offive, then the code may be locked from further access to all partiesexcept for certain high-level administrators with advancedpermissions/privileges. For example, if a copy of sensitive code isidentified in five or more new locations within a defined period of timethen an automated action may occur which prevents certain access andother functions until the matter is resolved. Another operation may be arepository identification process where the repositories storing thecode are identified and are required to be approved to alleviate orremove an unauthorized action.

One example of a period of time used as a basis for code security mayinclude 48 hours, one week, etc., that the code is tracked, monitored,and the results are compiled and compared to acceptability thresholds todetermine if certain users are required to have their access privilegesrevoked. If the violation is identified based on unacceptable storagelocations or other criteria (e.g., thresholds instances), then userrights of those having low-level rights or those who accessed the codeduring the period of analysis may lose their access privileges. Anothercriteria may be counting the number of duplications, such as clonescreated and where the clones are stored.

The one or more automated actions taken by the server code managementapplication may include, upon identifying a rule violation, one or moreof revoking user profile code access permissions, locking access to thesensitive code segments, and preventing code egress operations. The codeegress operations may include one or more of moving the code, copyingthe code and storing the code in a new data storage location or otheractions. One type of unacceptable egress operation may be the copying ofdata to a thumb drive, downloading a file to a remote storage location,‘desktop’ device location, etc. The type of egress action may be a copyaction which is identified during the attempted code event. Yet anothertype of egress action may be a copy action performed prior to thediscovery of the action. In this case, the libraries or other accessiblelinks may be disabled to cause the copied code to be useless sincereferences to exterior files and sources may be unobtainable after theremedial actions are taken once the code egress is discovered.

In general, code developers should be able to write and edit code butnot remove the code. One approach may be blocking egress actions, forexample, metadata can be monitored on a file, such as an attempted copyaction of a file, that can be blocked as a data loss prevention tool.Another approach is to block the port used currently or normally used bythe server during code access sessions. Also, the code does not have tobe a file and instead could be a piece of code, such as a segment oftext data. Also, a token may be used as an authentication factor, suchas a username and password, and/or other information, such as a hardwareaddress.

One approach may include adding context to the code files and data lossprevention (DLP) agents can use identify and use the context to enforcedata loss prevention rules. Context may include repository name, author,and other custom information such as project name, confidentialitylevel, etc. The context can be applied as external attributes (metadata)information on the file. Another approach is to detect and enforce dataloss similar to DLP agents but selectively for certain sensitive codesegments and files. Another example may provide the ability to monitorand block code egress actions as a GITHUB type of pre-commitment andpre-push check. For example, blocking a push of an enterprise codesegment or file to a public repository.

One example process may include identifying the code being accessed byidentifying the file containing the code being accessed and identifyinga metadata tag stored in the file and applying a metadata tag rule tothe file during the attempted action in an effort to block access to thecode. The metadata may require the user credentials be checked and thenthe action to check must identify a necessary credential. The processmay also include determining whether the metadata tag is stored in thecode responsive to the attempted action taken to the code and the actionmay cause the metadata tag to be retrieved and the permissions to beidentified for the user profile. The process may also include monitoringcode actions applied to the code by a user device during a code accesssession, identifying an egress code action attempted to the code as atrigger to perform one or more rules to the code actions. The processmay also include applying a hash key to one or more code segments tocreate a hash value responsive to the egress code action and applyingthe hash key to the one or more code segments may be performed to createthe hash value responsive to the egress code action and this includesapplying the hash key to only a portion of the one or more codesegments. The process may also include permitting code egress from aserver associated with the code for a period of time, and when theperiod of time has lapsed, blocking subsequent code egress actionsreceived.

Example embodiments provide ways to enforce software code protectionsand modifications to protect code from unauthorized sources and to trackthe use of the code on developer workstations. Further to codeprovenance and application of permissions/restrictions to the code, thecode may be accessed and then annotated, tracked, modified, according tothe code's history throughout the cloud and/or the enterpriseenvironment and the user profiles/devices associated with the codeevents. Also, the code may be periodically traced to identify all suchevents which have occurred over a period of time which includeaccessing, modifying, egress code operations (e.g., moving code, copyingcode, etc.), testing, authorization to access the code, etc.

FIG. 6A illustrates an example network configuration for applying codesecurity via token access according to example embodiments. Referring toFIG. 6A, an example code limited access management configuration 600includes an enterprise server 104 as a server with access and/or storagethat maintains code. When a user profile attempts to access code, theuser profile of the client device may be retrieved from memory. Theclient agent application 614 may communicate to a server agentapplication 612 which monitors the client actions and reports theactions to an authority. Also, any violations to the rights of theclient device and/or user profile may cause the privileges to beautomatically revoked.

The enterprise server 104 may store the code in a code repository server120, which may be local or at a remote site. When a code retrievalaction 622 is received from a client device, the code 642 may beidentified as a particular segment, group, file or set of files whichare identified as having a particular designation, such as a restrictionor open policy. Once the client profile is identified as having accessto the code, a certain level of access may be applied. In this example,the user profile may have access to only a portion of the code, or thecode may be required to be accessible but not viewable. The regular codein its regular state 642 may be inaccessible due to restrictions on theaccess of the client. The access may require ongoing communication viathe agent application 614 and its continued communication 622 with theserver agent application 112. The limited access commands 606 or list ofacceptable commands may be stored in a list or reference directory ofthe agent application 612.

In one example, when a command is received and processed by the serveragent 612, the command is screened to determine whether it is acceptablebased on the limited access commands 606. The token of the client thatis being used to provide code access may be revoked via a tokenmanagement function 608, which is invoked if the command is identifiedas invalid or not within the scope of the client profile. In thisexample, the code may be accessible for testing purposes but not formodification, viewing, copying, etc. If the limited access privilegesare applied, the server 120 may retrieve the code 622 and modify thecode access by obfuscating the code's view 644 so the client devicemanaged by a user cannot view the code, however, the code directory maybe accessible to run a test cycle or perform other functions whichrelated to the code.

FIG. 6B illustrates an example network configuration for enforcing codesecurity via token access according to example embodiments. Referring toFIG. 6B, the configuration 650 demonstrates that the correspondingportions of code may be identified and the entire procedure of testingthe code may be logged. In the event that the client device isattempting to move, copy or duplicate the code, the egress attempt orother command violation 664 is identified by the agent and the actionmay be blocked by revoking 668 the token. For example, when a clientdevice attempts to copy the code from a server, such as by a clientdevice and profile that has test only permissions but not permission toremove the code, one approach is to block the egress action. Metadatacan be monitored in association with a data file, such as an attemptedcopy action of a file, that can be blocked as a data loss preventionoperation. The metadata may be a log of actions taken, such as an egressaction. The servers 120/104 can then audit the metadata to identifywhether a violation occurred and whether action to revoke the token isnecessary. Another approach may be to block the port used to attempt theegress action. The port may be a client device port, a network deviceport, a server port, etc. Also, the code does not have to be a file andinstead could be a portion of code inside a file that includes variouscode portions.

FIG. 6C illustrates an example network configuration for applyingdifferent tokens to different code segments according to exampleembodiments. Referring to FIG. 6C, the example configuration 670includes a process where a first token ‘A’ is applied to a first portionof the code 672 and a second token is applied ‘B’ to a second portion ofthe code 674. As the client device accesses a first code portion a firsttoken may be assigned. Each portion of the code accessed may invoke anew code segment being accessed and a new token applied. In thisexample, the code remains hidden from view due to the obfuscation of thecode, however, access to perform limited actions such as execution andtesting. When a token is revoked, the access to the code that wasaccessed for that token is also revoked.

FIG. 6D illustrates an example flow diagram of a process 690 forenforcing token access according to example embodiments. Referring toFIG. 6D, the process may include identifying a user profile with limitedaccess privileges to code and identifying whether credentials arerequired to perform one or more code events to code based on a status ofthe code 692, and receiving a token associated with one or more userprofiles seeking to perform the one or more code events 694, which maybe performed during a code access event or after the event. The tokenwill need to be authenticated by the server application or other entityresponsible for verifying the token authenticity. The process may alsoinclude permitting the one or more code events responsive toauthenticating the token 698. The process may also include identifyingthe one or more user profiles participating in a code developmentsession, forwarding a request for the token to one or more devicesassociated with the one or more user profiles, and monitoring one ormore code events to identify the token needed. The process may alsoinclude monitoring the one or more code events and determining sensitivecode is included in the one or more code events, such as code identifiedby metadata or by other data attributes of the code and identifying theone or more user profiles has limited access privileges to the code, theprocess may also include comparing received commands to permittedcommands associated with the limited access, and revoking the tokenassociated with user profile responsive to identifying the receivedcommand is not permitted. The method may also include applying the tokento a first code segment, identifying a code event associated with adifferent code segment, and receiving a second token and the secondtoken is authenticated and applied to the different code segment.

In general, code monitoring may include a server or devices which areconfigured to track instances of metadata or control data, such as:times, dates, location, user profiles, egress operations, copying,modifying, deleting, etc., associated with the code. For example, alertsmay include secrets identified, such as tokens used, private data,egress actions, such as policy violations, unauthorized actions, newpublic and private repositories, which are identified as storing thecode. The number of occurrences may be used to establish anacceptability/unacceptability threshold for action. For example, if thenumber of egress events for a period of time exceeds a threshold (T) offive, then the code may be locked from further access to all partiesexcept for certain privileged administrators. For example, if a copy ofsensitive code is identified in five or more new locations within adefined period of time then an automated action may occur which preventscertain access and other functions until the matter is resolved. Anotheroperation may be a repository identification process where therepositories storing the code are identified and are required to beapproved to alleviate or remove an unauthorized action.

One example of a period of time may include 48 hours, one week, etc.,that the code is tracked and the results are compiled and compared toacceptability thresholds to determine if certain users are required tohave their access privileges revoked. If the violation is identifiedbased on unacceptable storage locations or other criteria (e.g.,thresholds instances), then user rights of those with low-level rightsor those who accessed the code during the period of analysis may losetheir access privileges. Another criteria may be counting the number ofduplications, such as clones created and where the clones are stored.

The above embodiments may be implemented in hardware, in a computerprogram executed by a processor, in firmware, or in a combination of theabove. A computer program may be embodied on a computer readable medium,such as a storage medium. For example, a computer program may reside inrandom access memory (“RAM”), flash memory, read-only memory (“ROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), registers, hard disk, aremovable disk, a compact disk read-only memory (“CD-ROM”), or any otherform of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 7 illustrates an example computer system architecture700, which may represent or be integrated in any of the above-describedcomponents, etc.

FIG. 7 is not intended to suggest any limitation as to the scope of useor functionality of embodiments of the application described herein.Regardless, the computing node is capable of being implemented and/orperforming any of the functionality set forth hereinabove.

In computing node 700 there is a computer system/server 702, which isoperational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system/server 702 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, hand-held or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 702 may be described in the general context ofcomputer system-executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 702 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 7 , computer system/server 702 in cloud computing node700 is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 702 may include, but are notlimited to, one or more processors or processing units 704, a systemmemory 706, and a bus that couples various system components includingsystem memory 706 to processor 704.

The bus represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)bus, Video Electronics Standards Association (VESA) local bus, andPeripheral Component Interconnects (PCI) bus.

Computer system/server 702 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 702, and it includes both volatileand non-volatile media, removable and non-removable media. System memory706, in one embodiment, implements the flow diagrams of the otherfigures. The system memory 706 can include computer system readablemedia in the form of volatile memory, such as random-access memory (RAM)710 and/or cache memory 712. Computer system/server 702 may furtherinclude other removable/non-removable, volatile/non-volatile computersystem storage media. By way of example only, memory 706 can be providedfor reading from and writing to a non-removable, non-volatile magneticmedia (not shown and typically called a “hard drive”). Although notshown, a magnetic disk drive for reading from and writing to aremovable, non-volatile magnetic disk (e.g., a “floppy disk”), and anoptical disk drive for reading from or writing to a removable,non-volatile optical disk such as a CD-ROM, DVD-ROM or other opticalmedia can be provided. In such instances, each can be connected to thebus by one or more data media interfaces. As will be further depictedand described below, memory 706 may include at least one program producthaving a set (e.g., at least one) of program modules that are configuredto carry out the functions of various embodiments of the application.

Program/utility, having a set (at least one) of program modules, may bestored in memory 706 by way of example, and not limitation, as well asan operating system, one or more application programs, other programmodules, and program data. Each of the operating system, one or moreapplication programs, other program modules, and program data or somecombination thereof, may include an implementation of a networkingenvironment. Program modules generally carry out the functions and/ormethodologies of various embodiments of the application as describedherein.

As will be appreciated by one skilled in the art, aspects of the presentapplication may be embodied as a system, method, or computer programproduct. Accordingly, aspects of the present application may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present application may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Computer system/server 702 may also communicate with one or moreexternal devices 720 via a I/O adapter 724, such as a keyboard, apointing device, a display 722, etc.; one or more devices that enable auser to interact with computer system/server 702; and/or any devices(e.g., network card, modem, etc.) that enable computer system/server 702to communicate with one or more other computing devices. Suchcommunication can occur via I/O interfaces 724 of the adapter 726. Stillyet, computer system/server 702 can communicate with one or morenetworks such as a local area network (LAN), a general wide area network(WAN), and/or a public network (e.g., the Internet) via network adapter.As depicted, adapter 726 communicates with the other components ofcomputer system/server 702 via a bus. It should be understood thatalthough not shown, other hardware and/or software components could beused in conjunction with computer system/server 702. Examples, include,but are not limited to: microcode, device drivers, redundant processingunits, external disk drive arrays, RAID systems, tape drives, and dataarchival storage systems, etc.

Although an exemplary embodiment of at least one of a system, method,and non-transitory computer readable medium has been illustrated in theaccompanied drawings and described in the foregoing detaileddescription, it will be understood that the application is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions as set forth and defined by thefollowing claims. For example, the capabilities of the system of thevarious figures can be performed by one or more of the modules orcomponents described herein or in a distributed architecture and mayinclude a transmitter, receiver or pair of both. For example, all orpart of the functionality performed by the individual modules, may beperformed by one or more of these modules. Further, the functionalitydescribed herein may be performed at various times and in relation tovarious events, internal or external to the modules or components. Also,the information sent between various modules can be sent between themodules via at least one of: a data network, the Internet, a voicenetwork, an Internet Protocol network, a wireless device, a wired deviceand/or via plurality of protocols. Also, the messages sent or receivedby any of the modules may be sent or received directly and/or via one ormore of the other modules.

One skilled in the art will appreciate that a “system” could be embodiedas a personal computer, a server, a console, a personal digitalassistant (PDA), a cell phone, a tablet computing device, a smartphoneor any other suitable computing device, or combination of devices.Presenting the above-described functions as being performed by a“system” is not intended to limit the scope of the present applicationin any way but is intended to provide one example of many embodiments.Indeed, methods, systems and apparatuses disclosed herein may beimplemented in localized and distributed forms consistent with computingtechnology.

It should be noted that some of the system features described in thisspecification have been presented as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule may be implemented as a hardware circuit comprising custom verylarge-scale integration (VLSI) circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices, graphics processing units, or thelike.

A module may also be at least partially implemented in software forexecution by various types of processors. An identified unit ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions that may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified module need not be physically locatedtogether but may comprise disparate instructions stored in differentlocations which, when joined logically together, comprise the module andachieve the stated purpose for the module. Further, modules may bestored on a computer-readable medium, which may be, for instance, a harddisk drive, flash device, random access memory (RAM), tape, or any othersuch medium used to store data.

Indeed, a module of executable code could be a single instruction, ormany instructions, and may even be distributed over several differentcode segments, among different programs, and across several memorydevices. Similarly, operational data may be identified and illustratedherein within modules and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

It will be readily understood that the components of the application, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations.Thus, the detailed description of the embodiments is not intended tolimit the scope of the application as claimed but is merelyrepresentative of selected embodiments of the application.

One having ordinary skill in the art will readily understand that theabove may be practiced with steps in a different order, and/or withhardware elements in configurations that are different than those whichare disclosed. Therefore, although the application has been describedbased upon these preferred embodiments, it would be apparent to those ofskill in the art that certain modifications, variations, and alternativeconstructions would be apparent.

While preferred embodiments of the present application have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the application is to be definedsolely by the appended claims when considered with a full range ofequivalents and modifications (e.g., protocols, hardware devices,software platforms etc.) thereto.

While example embodiments have been particularly shown and described, itwill be understood by those skilled in the art that various changes inform and details may be made therein without departing from the scope ofthe embodiments encompassed by the appended claims.

What is claimed is:
 1. A method comprising: determining whether to blockan attempted action taken to the code based on user profile accessrights associated with the attempted action taken to the code and a codepermission assigned to the code which limits modifications; and blockingone or more of access to the code, access to a file containing the code,and a port used to connect to a server hosting the code when theattempted action taken to the code violates the code permission assignedto the code limiting modifications.
 2. The method of claim 1, furthercomprising: identifying the code being accessed by identifying the filecontaining the code being accessed.
 3. The method of claim 1, furthercomprising: identifying a metadata tag stored in the file containing thecode and applying a metadata tag rule to the file containing the codeduring an attempted action to block access to the code.
 4. The method ofclaim 3, further comprising: determining whether the metadata tag isstored in the code responsive to the attempted action taken to the code.5. The method of claim 1, further comprising: monitoring code actionsapplied to the code by a user device during a code access session;identifying an egress code action attempted to the code; and applying ahash key to one or more code segments to create a hash value responsiveto the egress code action.
 6. The method of claim 5, wherein applyingthe hash key to the one or more code segments to create the hash valueresponsive to the egress code action comprises applying the hash key toonly a portion of the one or more code segments.
 7. The method of claim1, further comprising: permitting code egress from a server associatedwith the code for a period of time; and when the period of time haslapsed, blocking the code egress from the server.
 8. An apparatuscomprising: a processor configured to: determine whether to block anattempted action taken to the code based on user profile access rightsassociated with the attempted action taken to the code and a codepermission assigned to the code which limits modifications; and blockone or more of access to the code, access to a file containing the code,and a port used to connect to a server hosting the code when theattempted action taken to the code violates the code permission assignedto the code limiting modifications.
 9. The apparatus of claim 8, whereinthe processor is further configured to: identify the code being accessedby identifying the file containing the code being accessed.
 10. Theapparatus of claim 8, wherein the processor is further configured to:identify a metadata tag stored in the file containing the code and applya metadata tag rule to the file containing the code during an attemptedaction to block access to the code.
 11. The apparatus of claim 10,wherein the processor is further configured to: determine whether themetadata tag is stored in the code responsive to the attempted actiontaken to the code.
 12. The apparatus of claim 8, wherein the processoris further configured to: monitor code actions applied to the code by auser device during a code access session; identify an egress code actionattempted to the code; and apply a hash key to one or more code segmentsto create a hash value responsive to the egress code action.
 13. Theapparatus of claim 12, wherein applying the hash key to the one or morecode segments to create the hash value responsive to the egress codeaction comprises applying the hash key to only a portion of the one ormore code segments.
 14. The apparatus of claim 8, wherein the processoris further configured to: permit code egress from a server associatedwith the code for a period of time; and when the period of time haslapsed, block the code egress from the server.
 15. A non-transitorycomputer readable storage medium configured to store instructions that,when executed, cause a processor to perform: determining whether toblock an attempted action taken to the code based on user profile accessrights associated with the attempted action taken to the code and a codepermission assigned to the code which limits modifications; and blockingone or more of access to the code, access to a file containing the code,and a port used to connect to a server hosting the code when theattempted action taken to the code violates the code permission assignedto the code limiting modifications.
 16. The non-transitory computerreadable storage medium of claim 15, wherein the processor is furtherconfigured to perform: identifying the code being accessed byidentifying the file containing the code being accessed.
 17. Thenon-transitory computer readable storage medium of claim 15, wherein theprocessor is further configured to perform: identifying a metadata tagstored in the file containing the code and applying a metadata tag ruleto the file containing the code during an attempted action to blockaccess to the code.
 18. The non-transitory computer readable storagemedium of claim 17, wherein the processor is further configured toperform: determining whether the metadata tag is stored in the coderesponsive to the attempted action taken to the code.
 19. Thenon-transitory computer readable storage medium of claim 15, wherein theprocessor is further configured to perform: monitoring code actionsapplied to the code by a user device during a code access session;identifying an egress code action attempted to the code; and applying ahash key to one or more code segments to create a hash value responsiveto the egress code action.
 20. The non-transitory computer readablestorage medium of claim 19, wherein applying the hash key to the one ormore code segments to create the hash value responsive to the egresscode action comprises applying the hash key to only a portion of the oneor more code segments.